This invention relates generally to methods and systems for handling subscriber data. More particularly, this invention relates to methods and systems for updating and modifying subscriber data, unallocating subscriber identities, and indicating that subscriber identities have been purged.
There are many types of public land mobile networks (PLMNs), e.g., a Global System for Mobile Communications (GSM), a Digital Cellular System for Mobile Communications (DCS 1800), and a Personal Communication System (PCS). These networks provide a wide range of services and facilities to mobile subscribers that are roaming around between individual cells of the mobile radio communication networks.
A Universal Mobile Telecommunications System (UMTS) is currently being standardized within the 3rd Generation Partnership Project (3GPP), which is a cross-regional cooperative project to develop a third generation standard which can be accepted in as many regions of the world as possible. The UMTS will build on the success of GSM.
Network entities communicate via a common signalling system. For example, in the GSM System, the Mobile Application Part (MAP) of the Signaling System No. 7 specified by CCITT is used to communicate between entities in the PLMN. Details of this signalling system are given in Digital Cellular Telecommunications System (Phase 2+), Mobile Application Part (MAP) specification, TS GSM 09.02 v.5.6.00, which is incorporated herein by reference. The UMTS MAP will be based on the latest version of GSM MAP, with the minimum number of modifications possible.
The UMTS will support both circuit switched data communication, as used in traditional voice networks and packet switched communication, as provided by, e.g., the General Packet Radio Service (GPRS). Thus, the UMTS will be useful for exchanging voice and non-voice data quickly and efficiently.
FIG. 1 illustrates an exemplary network architecture for UMTS. In FIG. 1, a mobile station (MS) communicates with one or more Public Land Mobile Networks Each PLMN includes one or more Mobile Switching Centers (MSCs) for performing circuit switching for the MS.
A first network (PLMN1) is considered the Home PLMN (HPLMN) and includes a Home Location Register (HLR) containing subscriber data for subscribers to the network. The HPLMN also includes a Gateway GPRS Support Node (GGSN) for enabling packet-switched communication.
PLMN2 and PLMN3 are considered visiting PLMN and include one or more Visitor Location Registers (VLRs) for storing data regarding subscribers to other networks that may be roaming in the network. PLMN2 and PLMN3 also include Serving GPRS Support Nodes (SGSNs) for supporting packet switched communication.
The HLR of PLMN1 communicates with VLR1 (of PLMN2) and VLR2 and VLR3 (of PLMN3) for updating subscriber information, e.g., when a subscriber roams into an area served by one of these VLRs. The VLRs also communicate with each other. For example, when a subscriber roams into a new location area served by a VLR, this VLR referred to as a xe2x80x9cnew VLRxe2x80x9d, the VLR serving the location area in which the subscriber was previously located, i.e., the xe2x80x9cprevious VLRxe2x80x9d, communicates with the new VLR, providing subscriber information.
The SGSNs are at the same hierarchal level and function in a similar manner as the MSCIVLRs, but for packet switched communication for subscribers roaming between the service areas of the SGSNs. The SGSNs keep track of the location of the GPRS user, perform security functions, and handle access control. The SGSNs communicate with the HLR to obtain subscriber profiles. The SGSNs also communicate with each other, and the SGSN of PLMN3 communicates with the BSS which, in turn, communicates with the MSC connected to VLR2.
The GGSN is the interconnection point for packet data between the GPRS network and the public data network. The GGSN is connected to the SGSNs via an Internet Protocol (IP) backbone. User data, e.g., from a GPRS terminal connected to the Internet, is sent encapsulated over the IP Backbone. The GGSN is connected to the HLR for obtaining routing information for routing packet data to and from the SGSNs. The GGSN may also be connected to other GGSNs to facilitate roaming.
In the following, the difference between the mobility management procedures, in particular the location update procedures for the non-GPRS case, in standard GSM networks and the procedures in UMTS networks using the Super-Charger concept will be described. The differences are illustrated by first describing the location update procedures in standard GSM networks and then describing the corresponding procedures (and some additional procedures) used in UMTS networks employing the Super-Charger concept.
During a standard GSM location update procedure, during which a subscriber roams into an area served by a new VLR, the new VLR retrieves the International Mobile Subscriber Identity (IMSI) of the concerned subscriber. If the subscriber uses the IMSI for identification in a location update request sent to the new VLR from the subscriber, the IMSI is already available to the new VLR. However, if the subscriber uses a Temporary Mobile Subscriber Identity (TMSI) for identification so as to protect the integrity of the subscriber identity, the new VLR has to retrieve the IMSI from the previous VLR.
This may be understood with reference to FIG. 2 which illustrates a signaling sequence for a location update procedure in a standard GSM network in which the MS identifies itself with the TMSI. In FIG. 2, the BSS nodes and the authentication procedure have been omitted for simplicity.
As shown in FIG. 2, the location update procedure begins with the MS sending a location update request to the new VLR. The previous VLR is identified via an old location area identity, which is included in the location update request from the MS. The new VLR then requests the IMSI from the previous VLR by sending a MAP SEND ID request message, including the TMSI, to the previous VLR. The previous MSC/VLR returns the IMSI of the subscriber in the MAP SEND ID response message, together with any unused authentication triplets.
When the IMSI is retrieved, the new VLR sends a MAP UPDATE LOCATION indication message to the HLR of the concerned subscriber""s home network, i.e., the HPLMN. The HPLMN may, of course, be the same PLMN as that to which the new VLR belongs. The HLR then sends a MAP CANCEL LOCATION indication message to the previous VLR. The previous VLR then deletes the record of the concerned subscriber from its database and sends a MAP CANCEL LOCATION confirm message to the HLR. The HLR then sends the subscriber profile of the concerned subscriber to the new VLR in one or several MAP INSERT SUBSCRIBER DATA (ISD) indication message(s), depending on the amount of data. The new VLR responds with a MAP INSERT SUBSCRIBER DATA response message. After the ISD procedure, the HLR sends a MAP UPDATE LOCATION response message to the new VLR, and a similar acknowledgment is sent to the MS by the new VLR. Thereby, the location update procedure in the network is completed.
More details on the location update procedures in GSM can be found in TS GSM 9.02, xe2x80x9cDigital Cellular telecommunication system (Phase 2+); MAP specification.
In the GPRS case, the corresponding signaling is similar. The signaling between the new SGSN and the HLR and between the HLR and the previous SGSN is, in principle, the same as between the new VLR and the HLR and between the HLR and the previous VLR in the non-GPRS case. However, the signaling between the new SGSN and the previous SGSN is somewhat different.
This may be understood with reference to FIGS. 3 and 4 which illustrate the signalling sequences for a GPRS Attach procedure and a Routing Area Update Request, respectively, in a standard GSM GPRS network. The BSS nodes and the authentication procedure have been omitted for simplicity.
In the GPRS Attach case, the MS requests GPRS service from a new SGSN. If the request is successful, this changes the mobility management state of the MS from IDLE to READY. Referring to FIG. 3, in the GPRS Attach procedure, if the MS uses the Packet TMSI, (P-TMSI), i.e., the temporary identity corresponding to the TMSI in the non-GPRS domain for identification, the new SGSN requests the IMSI from the previous SGSN with an Identification Request message. The IMSI (and any unused authentication triplets) is returned from the previous SGSN to the new SGSN in an Identification Response message. From this point, the process proceeds, in principle, as in the non-GPRS case described above with regard to FIG. 2.
In the inter-SGSN Routing Area Update case, the GPRS-attached MS, i.e., an MS that is in a STANDBY or READY state moves from one routing area served by one SGSN to another routing area served by another SGSN. Referring to FIG. 4, the IMSI and unused authentication triplets are transferred from the previous SGSN to the new SGSN. The new SGSN requests data from the previous SGSN with a SGSN Context Request message. The IMSI and more data, e.g., the Packet Data Protocol (PDP) Context, which is needed to enable transfer of data packets from the previous SGSN to the new SGSN and from the GGSN to the new SGSN, are returned from the previous SGSN to the new SGSN in a SGSN Context Response message. In this case, the GGSN is also involved in the signaling procedure. From this point, the process proceeds, in principle, as in the non-GPRS case described above with regard to FIG. 2.
Every time a subscriber moves to a location served by a new VLR or SGSN, the subscriber data must be downloaded from the HLR in the HPLMN to the new VLR or SGSN serving the user and deleted in the previous VLR or SGSN. If the location areas associated with these entities are small or the subscriber frequently moves between the location areas, this downloading creates a large signalling load. This applies to subscribers moving within their home network and roaming subscribers. For roaming subscribers, international signalling costs are incurred.
The MAP INSERT SUBSCRIBER DATA (ISD) messages that are used for transmitting the subscriber profile of a concerned subscriber to a new VLR include rather large amounts of data, thus placing a significant load on the signaling networks, especially on the international signaling links in the case of roaming between different PLMNs.
A Super-Charger concept is being designed to reduce the signaling in the networks, mainly by eliminating the majority of the ISD messages but also by eliminating the MAP CANCEL LOCATION messages by which the subscriber profiles in the previous VLRs and SGSNs are deleted. This is achieved by not deleting the subscriber data from the VLR database when the subscriber leaves the service area of the VLR. Instead, the subscriber data is retained in the previous VLR and can be reused the next time the subscriber registers in the same VLR. Since the subscriber data is retained in the VLR, the MAP CANCEL LOCATION message from the HLR is unnecessary and can be eliminated. When the subscriber profile is already present in a new VLR, there is no need to transfer the subscriber profile from the HLR, provided of course that the subscriber has been registered in that VLR before. Thereby, the ISD message(s) are eliminated too.
It is important that the subscriber profile used in the VLR is up to date, i.e., that the subscriber profile used in the VLR is that same as that currently stored in the HLR. To ensure this data consistency, some kind of revision management mechanism for the subscriber profiles is needed. A time stamp and a sequence number associated with each new version of the subscriber profile have been suggested, among other solutions. The time stamp, sequence number, or other type of parameter, may be generally referred to as a revision management parameter.
A signaling sequence illustrating a location update procedure when the Super-Charger concept is used, provided that the subscriber has previously been registered in the new VLR and provided that the retained subscriber profile is up to date, is depicted in FIG. 5. The BSS nodes and the authentication procedure have been omitted for simplicity.
Referring to FIG. 5, when the MAP UPDATE LOCATION indication message is sent to the HLR by the new VLR, the revision management parameter associated with the version of the subscriber profile currently stored in the new VLR is included. The HLR compares the received revision management parameter with that associated with the subscriber profile version currently stored in the HLR and determines whether the subscriber profile stored in the new VLR needs to be updated. If updating is needed, the HLR transfers the updated subscriber profile and its associated revision management parameter to the new VLR in the ISD message(s). The new VLR then deletes the previously stored subscriber profile (and its associated revision management parameter) from its database and stores the received subscriber profile (and its associated revision management parameter) in its place. If the HLR determines that the subscriber profile version in the new VLR is the same as the one stored in the HLR, no ISD message is sent to the new VLR. Instead, the HLR sends the MAP UPDATE LOCATION response message to the new VLR, as shown in FIG. 5. If the revision management parameter is not included in the MAP UPDATE LOCATION message received from the new VLR, the HLR performs the standard location update procedures, i.e., the subscriber profile (without its associated revision management parameter) is transferred to the new VLR in ISD message(s).
When the HLR receives a MAP UPDATE LOCATION message including a revision management parameter, it marks the new VLR as xe2x80x9csupporting the Super-Charger conceptxe2x80x9d in its database. The HLR also checks its database to determine whether the previous VLR supports the Super-Charger concept. If the previous VLR does support the Super-Charger concept, the HLR does not send a MAP CANCEL LOCATION message. Otherwise, the MAP CANCEL LOCATION message is sent as in a standard GSM system.
More details on the location update procedures when the Super-Charger concept is used can be found in Tdoc, 3GPP N2-99 972, xe2x80x9c3rd Generation Partnership Project; Technical Specification Group Core Network; Technical Report on Super-Chargerxe2x80x9d from 3GPP, incorporated herein by reference.
The Super-Charger concept is equally applicable for the SGSN in the GPRS domain. It works in, in principle, the same way in this case. There are some differences that will be discussed below, as they become relevant.
There are a number of problems associated with the conventional Super-Charger concept. One problem is the efficiency.
The efficiency of the Super-Charger concept can be improved in several ways. One way is to attempt to further reduce the international signaling load due to the transfer of updated subscriber profiles in MAP INSERT SUBSCRIBER DATA messages.
Two other problems are related to the Temporary Mobile Subscriber Identity (TMSI). The TMSI is a short temporary identifier, which is unique only within one location area and which is reused as subscribers come and go in the location area. Hence, the TMSI value range is a limited resource. Normally, a TMSI is allocated to a subscriber upon a location update in a new location area. The TMSI is unallocated when the subscriber leaves the location area, thereby making it available for allocation to other subscribers. It can then, at the discretion of the operator, be reallocated during subsequent contacts between the subscriber and the network.
If the new location area is managed by the same VLR, the VLR has full control of what is happening and can unallocate the TMSI in the old location area as soon as the subscriber sends a location update request in the new location area. However, if the new location area is managed by another VLR, the unallocation of the TMSI in the old location area is triggered by the MAP CANCEL LOCATION message from the HLR to the previous VLR.
In the Super-Charger concept, the MAP CANCEL LOCATION message is removed, and consequently the TMSI is not unallocated in the normal way. In fact, the previous VLR is not made aware that the subscriber has left its service area. For the GPRS case, the P-TMSI is managed by the SGSN in a similar way, and the P-TMSI management is affected in the same way as the TMSI management by the removal of the MAP CANCEL LOCATION message.
Currently, there is no provision in the Super-Charger concept for unallocating the TMSI and the P-TMSI. Thus, the efficiency of the TMSI and the P-TMSI is decreased.
Another problem with the Super-Charger concept is that there is currently no provision for deleting subscriber profiles from a VLR and indicating that the profiles have been deleted to the HLR.
In the current GSM system, a subscriber profile can be removed from a VLR after a certain period, e.g., several days, of inactivity. In such a case, a MAP PURGE MS message is sent from the VLR to the HLR to inform the HLR of the action and to prevent unnecessary MAP PROVIDE ROAMING NUMBER request messages concerning the purged subscriber.
As new subscribers are served, the database of the VLR will keep growing. Thus, here is a need for a database management function in the VLR to discard old subscriber data (according to some algorithm) to prevent the database from becoming full.
According to the Super-Charger concept, when a subscriber record is deleted due to database management reasons, the HLR is not informed, as opposed to the standard GSM system where a MAP PURGE MS message is sent to the HLR.
The elimination of the MAP PURGE MS message means that there is a possibility that the HLR believes that the subscriber (whose record was deleted from the VLR) is still registered in the same VLR (if the HLR has not received a MAP UPDATE LOCATION message concerning the same subscriber from another VLR). This, in turn, means that the HLR may send a MAP PROVIDE ROAMING NUMBER request message to the VLR when a call is to be routed to the concerned subscriber. The VLR is then supposed to return the MAP PROVIDE ROAMING NUMBER response message including an Absent Subscriber Error with the new diagnostic information xe2x80x9cMS Purgedxe2x80x9d. Upon reception of this xe2x80x9cMS Purgedxe2x80x9d indication, the HLR can set the xe2x80x9cMS Purged for Non-GPRSxe2x80x9d flag in the subscriber record of the concerned subscriber.
This handling of the MAP PROVIDE ROAMING NUMBER request has yet another consequence. It means that upon receipt of a MAP PROVIDE ROAMING NUMBER request for a subscriber for whom there is no data record in the VLR, the VLR must be able to distinguish between the case when the subscriber profile was removed by the Super-Charger database management function, in which case the MAP PROVIDE ROAMING NUMBER response message is returned to the HLR with the error information described above, and the case when the subscriber profile was lost due to a VLR restart, in which case the normal VLR database restoration procedure is initiated.
It has also been proposed to eliminate the MAP SEND IDENTIFICATION messages by which the new VLR retrieves the IMSI from the previous VLR, in case the subscriber used the TMSI for identification in the location update request. Instead, the new VLR is supposed to retrieve the IMSI from the MS via the MAP PROVIDE IMSI procedure.
In the current GSM system, the HLR can include a xe2x80x9cFreeze TMSIxe2x80x9d parameter in the MAP PURGE MS response message. This parameter may be used if the VLR number stored for the concerned subscriber in the HLR is the same as the VLR number received in the MAP PURGE MS message. This is a precaution for preventing double allocation of a TMSI, e.g., when the HLR has not received a location update for the subscriber in another VLR, i.e., when, according to the records of the HLR, the subscriber is still located in the service area of the VLR from which its subscriber record was purged. The frozen TMSI is made available again at a subsequent location update by the concerned subscriber in the same VLR, at the reception of a MAP CANCEL LOCATION message for the concerned subscriber, or, in extreme cases, by operation and maintenance interventions.
In a Super-charged network, the above-described protection against double allocation of a TMSI is removed, together with the MAP PURGE MS message, thus creating ambiguity problems. The P-TMSI management is affected similarly by the removal of the MAP PURGE MS message from the SGSN to the HLR and the consequently removed possibility for the HLR to reply with a xe2x80x9cFreeze P-TMSIxe2x80x9d parameter.
The removal of the Map Purge MS message also creates a problem in network requested PDP context activation in preparation for mobile terminating GPRS packet delivery. To illustrate this problem, it is useful to describe the successful and the unsuccessful cases of network-requested PDP context activation. FIG. 6 illustrates a signaling sequence for the successful case of a network-requested PDP context activation. The BSS nodes have been omitted for simplicity.
As shown in FIG. 6, when a mobile terminated PDP Packet Data Unit (PDU), i.e., a data packet, arrives at the GGSN, the GGSN interrogates the HLR for routing information using a MAP SEND ROUTING INFO FOR GPRS request message. If the concerned subscriber is not known by the HLR to be unreachable, the HLR returns the SGSN Address of the SGSN currently serving the subscriber in a MAP SEND ROUTING INFO FOR GPRS response message. The GGSN then sends a PDU Notification Request to the SGSN, including the IMSI, the PDP Type and the PDP Address. The SGSN acknowledges this message by sending a PDU Notification Response to the GGSN and sends a Request PDP Context Activation message to the MS. After this, the actual PDP Context Activation Procedure begins between the GGSN and the MS.
The GGSN may store the address of the SGSN with which the GGSN established the last PDP context for the concerned subscriber. The stored SGSN address would be valid during a certain limited time, during which an inquiry to the HLR would be prevented. However, it is very unlikely that the subscriber record would be purged from the SGSN database during this limited time. If a subscriber record had to be discarded, a database management function would rather choose to discard a subscriber record that had not been used for a very long time.
If the destination subscriber is marked as not reachable in the HLR, the HLR indicates this in its MAP SEND ROUTING INFO FOR GPRS response message to the GGSN so that the GGSN can avoid wasting signaling resources and processing power on an unsuccessful PDU Notification Request to the SGSN.
The signaling sequence for the unsuccessful case of a network-requested PDP context activation is illustrated in FIG. 7. The BSS nodes have been omitted for simplicity.
As shown in FIG. 7, if the PDP Context activation fails before the Request PDP Context Activation message is sent from the SGSN to the MS, e.g., because the concerned IMSI is not known in the SGSN, e.g., because it was previously discarded by the database management function, the SGSN returns an error indication to the GGSN in the PDU Notification Response message. The indicated error cause may be, e.g., xe2x80x9cIMSI Not Knownxe2x80x9d or xe2x80x9cMS GPRS Detachedxe2x80x9d. Another scenario is that the Request PDP Context Activation message is sent to the MS, and then the PDP Context Activation fails. The SGSN then indicates the error cause in a PDU Notification Reject Request message to the GGSN, but this scenario is not relevant to this discussion.
When the GGSN receives a PDU Notification Response message (or a PDU Notification Reject Request) with an error indication from the SGSN, it reports the failure and the reason for the failure to the HLR in a MAP FAILURE REPORT indication message. This message is confirmed by the HLR with a MAP FAILURE REPORT confirm message. The error causes reported in the MAP FAILURE REPORT indication message to the HLR may be, e.g., xe2x80x9cSystem Failurexe2x80x9d, xe2x80x9cData Missingxe2x80x9d, xe2x80x9cUnexpected Data Valuexe2x80x9d or xe2x80x9cUnknown Subscriberxe2x80x9d (all are values of the User Error parameter). Upon reception of the MAP FAILURE REPORT indication message, the HLR sets a xe2x80x9cMobile Station Not Reachable for GPRSxe2x80x9d (MNRG) flag for the concerned subscriber (if the flag is not already set). The HLR may also indicate the reason in a xe2x80x9cMobile Not Reachable Reasonxe2x80x9d (MRRR) parameter.
Before sending the MAP FAILURE REPORT indication message, if the error cause was xe2x80x9cIMSI Not Knownxe2x80x9d, the GGSN may try to retrieve a new SGSN address (assuming that the MS might have moved to another SGSN) by sending a MAP SEND ROUTING INFO FOR GPRS request message to the HLR. If a SGSN address other than that already tried is returned from the HLR, the network-requested PDP context activation procedure starts all over again. Otherwise, the MAP FAILURE REPORT indication message is sent to the HLR.
As described above, a request for a roaming number concerning a subscriber whose record has been discarded from the VLR by the Super-Charger database management function results in a xe2x80x9cMS Purgedxe2x80x9d indication from the VLR to the HLR, so that the HLR subsequently can set the xe2x80x9cMS Purged for Non-GPRSxe2x80x9d flag for the concerned subscriber, thereby preventing subsequent attempts to reach the concerned subscriber with mobile terminated calls or short messages. However, there is no corresponding way for the HLR to receive the information that the concerned MS has been discarded from the SGSN database. Hence, the xe2x80x9cMS Purged for GPRSxe2x80x9d flag is never set in the HLR. Thus, unsuccessful network-requested PDP context activation (i.e., mobile terminated GPRS packet delivery attempts) and mobile terminated short messages destined for the concerned subscriber may still be routed to the SGSN if the HLR has not received a MAP UPDATE GPRS LOCATION indication message from another SGSN. This packet or short message cannot be forwarded by the SGSN to the MS. If the xe2x80x9cMS Purgedxe2x80x9d status could be conveyed from the SGSN to the HLR as a consequence of an unsuccessful network-requested PDP context activation for a subscriber whose record has been discarded from the SGSN by the Super-Charger database management function, the efficiency of the Super-Charger concept would be improved.
Thus, there is a need for techniques for solving the problems in subscriber data handling in the Super-Charger concept.
It is therefore an object of the invention to improve the efficiency of the handling of subscriber data.
According to exemplary embodiments, this and other objectives are met by a method and system for handling subscriber data for a subscriber roaming in a network including a home network entity containing information regarding subscribers to the network and one or more visitor network entities containing information regarding subscribers to one or more other networks. The network may support circuit-switched communication and/or packet-switched communication.
According to a first embodiment, a method and system are provided for updating a subscriber profile. An update location request is received at a new visitor network entity serving an area into which the subscriber roamed from an area served by a previous visitor network entity, and the update location request is indicated to the home network entity. A determination is made whether a subscriber profile of the subscriber stored in the new visitor network entity needs updating and whether conditions for updating the subscriber profile stored in the new visitor network entity from the previous visitor network entity are met. If the subscriber profile needs updating and the conditions are met, the subscriber profile stored in the new visitor network entity is updated from the previous visitor network entity.
According to a second embodiment, a method and system are provided for sending only modifications to a profile for updating the profile. At the home network entity, a request is received to update a subscriber profile stored in a visitor network entity. A determination is made whether modifications recorded in the home network entity are sufficient to enable updating of the subscriber profile. If the modifications recorded are sufficient, the modifications are sent from the home network entity to the visitor network entity.
According to a third embodiment, a method and system are provided for handling unallocation of subscriber identities. As one alternative, a subscriber identity may be unallocated upon receipt of a request for identification of a subscriber at a previous visitor network entity serving an area from which the subscriber has roamed. As another alternative, a determination is made whether a predetermined amount of time has elapsed since the last contact between the subscriber and the network. If so, the use of a subscriber identity of the subscriber in the network is prevented.
According to a fourth embodiment, a method and system are provided for handling packet context activation failure. A determination is made whether an attempted packet activation by the network for a subscriber at one of the visitor network entities is successful. If the packet activation fails, the failure is indicated to the home network entity, and a determination is made whether the failure was caused because a subscriber record was purged. If the failure was caused because a subscriber record was purged, the home network entity records that a subscriber profile for the subscriber has been purged.